Distributed Environment Controlled Access Facility

ABSTRACT

A computer implemented web based access control facility for a distributed environment, which allows users to request for access, take the request through appropriate approval work flow and finally make it available to the users and applications. This program also performs an automatic task of verifying the health of data, access control data as well as the entitlements, to avoid malicious user access. The system also provides an active interface to setup a backup, to delegate the duty in absence. Thus this system provides a comprehensive facility to grant, re-certify and control the entitlements and users in a distributed environment.

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims benefit of U.S. Provisional ApplicationNo. 60/375,239, filed Apr. 24, 2002.

BACKGROUND OF INVENTION

[0002] 1. Field of the Invention

[0003] The present invention generally relates to computer implementedcontrol facility and support tools, and more particularly, a web basedaccess control facility in a distributed environment.

[0004] 2. Background Description

[0005] In a complex system like a manufacturing environment spreadacross the globe, it is very difficult to manage and control the accessto various subsystems. Current systems have their own access controlwith no uncial approach to the users from other systems andapplications. Most of the systems cannot provide cross system interoperability due to the manual process of providing access.

[0006] This manual process further cripples the task of tracing andkeeping track of users who no longer use the system or who left aposition and no longer need the use the system. This is potentially adangerous security breach if the user is left with access. This problembecomes acute and chronic if the systems are distributed and spreadacross geographies.

[0007] Further in a manual process, delegation of duty, in absence ofthe representative, can be chaotic and improper. In a manual systemdelegation can be done by communications such as eor phone call.However, there is an isolated chance of it getting lost, and becoming ablock in the system. This can also become a security problem since eorphone calls, as other modes of communication, can be diverted,mischaracterized or tapped.

[0008] In traditional prior art access control facilities, the entireauthentication is done at one time and for a limited set or domain ofusers. One of the limitations or handicaps of the prior systems is datacentralization and data ownership. One owner or no owner is identifiedfor the data, which severely limits the authentication of data andusers. Since only the owner of the data can authenticate users, dataownership is a critical part of a distributed system.

[0009] There are automated systems in the prior art that deal withentitlements and access, especially in our webworld. However, they tendto be centralized and targeted to specific applications. An example isU.S. Pat. No. 6,223,292 issued to Dean et al. In this invention usersare provided with graduated services provided by a media server. Whenthe media server receives a streaming service request from a user themedia server evaluates the user according to service level by analyzingthe password. A second invention is U.S. Pat. No. 6,115,821 issued toNewby et al. which provides an access control processor for display of amessage related to an authorization status of an information receiver,when the information is provided by a plurality of service providers.Another invention of this type is U.S. Pat. No. 5,890,140 issued toClark et al. which integrates interactive financial services to allowaccess to multiple financial products from a single location.

[0010] A webentitlement system which is ideally suited for investmentresearch reports and investment advisors and for corporate financialinformation is U.S. Pat. No. 5,864,871 to Kitain et al. It bases itsentitlements on a user identification code and password.

SUMMARY OF INVENTION

[0011] As a result of the distributed nature of access control, datachanges and verifications, as well as user migrations from one system toanother system becomes a challenging task. This makes it necessary forcreation of different roles. It also poses a new problem of transfer ofownership of data and users, which happen seamlessly without affectingthe user.

[0012] Accordingly a facility of separation of duties, automaticrevalidation of users, content visibility based on the type of user,fully automated request, review and authentication process, as well as asystem controlled delegation of duty in case of absence is needed.Further, its important to have a capability to work across systems andto provide a seamless access to different facilities from one point.

[0013] It is therefore a purpose of the present invention to provide anintegrated access control facility for a distributed environment.

[0014] Another purpose of the present invention to provide a system thatcan allow a user to setup data without altering the system structure.

[0015] It is yet another purpose of the present invention to allow usersto request the necessary access (hereinafter known as entitlements),from a common interface.

[0016] It is yet another purpose of the present invention to checkautomatic separation of duties with a capability of manual override ifnecessary.

[0017] It is another purpose of the present invention to provideautomated access approval work flow, with a system action after aconfigurable time.

[0018] It is yet another purpose of the present invention to provide afacility for delegation of duty in the absence of the entitled user.

[0019] It is yet another purpose of the present invention to provide afacility to setup and change the data ownership as well as users.

[0020] It is yet another purpose of the present invention to revalidatedata and users automatically on expiration with a manual override tostart the process at any time.

[0021] And finally, another purpose of the present invention is tocontrol the data visibility available for request.

BRIEF DESCRIPTION OF DRAWINGS

[0022] The foregoing and other objects, aspects and advantages will bebetter understood from the following detailed description of a preferredembodiment of the invention with reference to the drawings, in which:

[0023]FIG. 1 is a general outline in graphical form of the preferredembodiment DECAF system.

[0024]FIG. 2 is an outline in graphical form of the preferred data setupflow followed to make the preferred embodiment DECAF system operational.

[0025]FIG. 3 defines in graphical form the preferred process of definingthe Separation Of Duties matrix used in the approval process identifiedin FIG. 4.

[0026]FIG. 4 describes in graphical form the entitlement requestapproval work flow for the preferred embodiment DECAF system.

[0027]FIG. 5 details in graphical form the preferred Separation ofDuties approval work flow.

DETAILED DESCRIPTION

[0028] The preferred embodiment of a distributed environment controlledaccess facility (DECAF) system requires the listed actors for the smoothsetup and function of the system. An Administrator actor which isresponsible for application setup and database administration. Approveractors which approve User actor requests for entitlements and projects.Backup Approvers that approve in the absence of the primary Approveractors. A Business Operations Owner actor who initializes the customerenablement process. A Business Analyst actor which is responsible forentitlement definitions. A Customer Enabler actor which enables thecustomer. A Customer Owner actor who approves the enablement request forthe customer. Deploy Lead actors that own an application_s entitlementsand any actions on said entitlements. Manager actors which act asapprovers for internal, User actors. A Master Point of Contact (MPOC)who is the preferred embodiment DECAF system contact for external Useractors and Point of Contact actors. Point of Contact actors which areresponsible for external User actors and projects for a customer. AProject Enabler actor who is responsible for the creation andmaintenance of projects. A Report User actor which reports visibilityentitlement. A Revoke Administrator actor which is responsible forrevoking User actors and entitlements. User actors which encompass anyusers of the preferred embodiment DECAF system not acting in thecapacity of a previously defined actor.

[0029] Referring now to the drawings, and more particularly to FIG. 1,which is the behavioral example of the preferred embodiment DECAFsystem. This example includes an User actor in block 100, a targetapplication in block 110, and Application Program Interface (API) callsto the preferred embodiment DECAF system in block 120.

[0030] The User actor does not have a defined point of entry. That is,entry may be initiated from within the organization_s computer networkswhere the present invention is located (hereinafter referred to asintranet) or entry may be initiated from outside the organization_scomputer networks where the present invention is located (hereinafterreferred to as an Internet).

[0031] The target application, depicted as a single application for easeof demonstration, may be any number of applications residing on anynumber of computers within an organization_s intranet structure. Thetarget application may also be any number of applications residing onany number of computers within the Internet.

[0032] In the preferred embodiment of the present invention, the normaloperating work flow is defined as such: The user actor in block 100attempts to access the target application in block 110. The targetapplication in block 110 sends a request to the user actor for specificinformation. Once the user actor returns the requested information tothe target application, the target application sends a series ofauthentication and authorization requests on behalf of the user actor inblock 100 to the present invention using a the set of API calls in block120. The Access Repository in block 190 compares the informationreceived from the target application via the APIs in block 120 toinformation that was created and persisted when the target applicationand user actor were defined to the preferred embodiment DECAF system.The Access Repository of the preferred embodiment DECAF system in block190 returns responses to the API calls from the target application inblock 110 detailing if the user actor in block 100 is authorized to usethe target application and if applicable, the level of access the useractor has in the target application. The target application receives theinformation and reacts the user actor accordingly.

[0033] As previously stated, target applications must be defined in thepreferred embodiment DECAF system. This is abstractly represented inFIG. 1 by blocks 130, 140, and 170. Referring now to FIG. 2,applications are defined by the DECAF administrator actor and owned bythe Deploy Lead actor. Target application setup is accomplished by theadministrator actor of the DECAF system entering the required andoptional information into the Application Setup screen in block 200. Therequired information includes, but is not limited to: 1) Applicationname which is a unique identifier for the application being defined. TheApplication will be referred to by this identifier throughout thepreferred embodiment DECAF system. 2) Application description which is ageneral description of the application being defined to the preferredembodiment DECAF system. 3) A multiple userid selection which determinesif a user actor can have multiple userids. 4) A multiple entitlementselection which determines if a multiple entitlements are permitted. Theoptional information includes, but is not limited to: 1) Applicationlevels, if applicable, which is the number of base levels to be usedwhen defining the application accessibility scope. 2) LDAP group, ifapplicable, defines the LDAP group used for authentication.

[0034] Upon defining an application to the preferred embodiment DECAFsystem, entitlements are defined for the application in block 210. Anentitlement is the primary data element in the preferred embodimentDECAF system and forms the basis of all other data elements such asprojects, profiles, and approvers. A Business Analyst actor enters therequired and optional information using the preferred embodiment DECAFsystem Entitlement setup screens. The required information includes butis not limited to: 1) The entitlement name which is unique within theapplication. 2) The entitlement description which is a description ofthe entitlement. 3) The level of approvers which defines the maximumnumber of approvers required to approve a request for the entitlement.4) The active dates define the start and expiration dates for theentitlement. The optional information includes but is not limited to: 1)Separation Of Duties (SOD) check determines if the SOD table isreferenced during the entitlement request approval process for thespecified entitlement. 2) Entitlement type which describes whether theapplication entitlement is available to external user actors, internaluser actors, both external and internal user actors, or reserved forDECAF administration actors.

[0035] Entitlements are not available for User requests until Approverusers are defined. Also, entitlements will not be visible for Userrequest if the request dates are beyond the expiration dates of thedefined entitlements.

[0036] Entitlements may be grouped into projects which allow an Useractor to request and receive multiple entitlements within a singlerequest and approval process. A Project Enabler actor is allowed todefine projects using the setup screens provided by the preferredembodiment DECAF system. Information required to define a projectincludes but is not limited to; project name, project description,project expiration dates, and number of project approvers. Once thisinformation is entered, the entitlements to be added to the project areselected. As before with entitlements, projects are not available forUser requests until Approver actors are defined.

[0037] The Separation Of Duties matrix of the preferred embodiment DECAFsystem in block 220 is defined after the application and entitlementshave been defined and before the entitlements are made available foraccess requests. Referring now to FIG. 3, a Business Analyst actor willuse the SOD setup screens of the preferred embodiment DECAF system todefine the SOD matrix which may include all defined applications andentitlements. The targeted applications and entitlements are selectedfrom the list of available entitlements in block 300. A grid is createdand displayed by the preferred embodiment DECAF system containing theselected entitlements as columns and all entitlements as rows in block310. The Business Analyst actor then selects the intersection where aconflict might exist in block 320. The conflict options are: no conflictwhere a request is passed to defined approvers, definite conflict wherea request is rejected without going to defined Approver actors, orpossible conflict where the request is flagged for review and passed todefined Approver actors. Upon completion of the grid, the Deploy Leadactors must approve the SOD matrix before it may be used in theentitlement request approval process.

[0038] Referring now back to FIG. 2, Approver actors and Backup Approveractors are defined by Deploy Lead actors and Project Enabler actors inblock 230 using screens provided by the preferred embodiment DECAFsystem. Without this step, entitlement and project requests can not beapproved for an application. Deploy Lead actors and Project Enableractors have visibility only to entitlements and projects, respectively,which they own. The process for defining Approver actors and BackupApprover actors is the same for both Deploy Lead actors and entitlementsand Project Enabler actors and projects. Therefore, Deploy Lead Actorsand entitlements will be used for describing the process. 1) Theapplication is selected from a list of available applications. 2) Theentitlement is selected from a list of available entitlements. 3) Anumber of rows equal to the number of approvers specified when theentitlement was defined is presented for the Deploy Lead actor to defineapprovers with. 4) The approver sequence number is selected for eachrow. 5) The Approver actor name for each row is selected from a list ofvalid internal User actors. One row must be defined as_Manager/POC_(—).6) The type of User actor the Approver actor will approve is selectedfrom the choices internal, external, or both. 7) Approver actors toperform the reprocess are selected from the list of defined Approvers.The reprocess is detailed in a later section. Once Approver actors aredefined for an entitlement or project the entitlement or project isavailable for internal User actor requests in block 240. Blocks 250 and260 contain the processes for making an entitlement or project availableto external User actors. Referring now to block 250, the Main Point ofContact (MPOC) actor assigns or scopes an entitlement, project., or mixof either to a Point of Contact (POC) actor, which was previouslycreated by the MPOC in the preferred embodiment DECAF system. The POCactor in block 260 in turn scopes or assigns an entitlement, project, ormix of either to User actors under the POC actor_s responsibility. Anentitlement or project is now available for external User actor requestsin block 270.

[0039] Block 290 encompasses the User actor registration and validationprocess. A User actor must be validated in the preferred embodimentDECAF system before entitlements can be requested for the User actor.The registration and validation process begins with the prospective Useractor completing an online registration form. The prospective Useractor_s information is validated against the organization_s internalemployee list to determine if the user will be validated as an internalor external User actor. Confirmation of User actor status is immediatein the preferred embodiment DECAF system. Internal User actors areassociated with an internal preferred embodiment DECAF system managerfor approval of entitlement requests. External User actors are assignedto the MPOC actor who associates the external User actor to a relevantPOC actor in block 280 for approval of entitlement request within thepreferred embodiment DECAF system.

[0040]FIG. 4 contains the detailed actions of a User actor entitlementrequest abstracted in FIG. 1 by blocks 100, 150, 160, 180, and 190. TheUser actor submits a request for entitlement in block 400. An SOD checkis performed at the beginning of the process in block 405. FIG. 5provides the details of the SOD check process. The results of the SODcheck are tested in block 410. If the request is rejected by the SODcheck in block 405, the flow passes to block 490 and the process iscomplete. If the request is not rejected by the SOD check, the Useractor is determined to be internal or external in block 415.

[0041] A request from an external User actor is passed to theresponsible POC for approval in block 430 then to other definedapprovers, if applicable, in blocks 445 and 450 if the POC approves therequest. Notification of the approval is sent to the User actor in block455. Otherwise, if the POC rejects the request in block 430, a record ofthe rejection is archived and the User actor is notified of therejection in block 460.

[0042] A request from an internal User actor is passed to block 420 todetermine if a manual SOD check is required in block 425. The internalUser actor_s manager approves or rejects the request in block 430 in thepreferred embodiment of the DECAF system. If the manager rejects, arecord of the rejection is archived and the User actor is notified ofthe rejection in block 460. If the manager approves the request and SODwarnings were flagged from the manual check in block 425, the managerprovides a reason for ignoring the SOD warning in block 440. The requestis passed to other defined approvers, if applicable, in blocks 445 and450. Notification of the approval is sent to the User actor in block455. Notification of rejection is sent to the User actor in block 460.

[0043] Once a User actor_s request is approved, the User actor hasaccess to the target application until the entitlement expires or isrevoked.

[0044] Revocation is accomplished in three ways in the preferredembodiment DECAF system. A userid for a User actor can be revokedaffecting all entitlements for the User actor. Specific entitlements fora User actor can be revoked. A userid for a User actor can be lockedpreventing use of the userid until it is unlocked. This option limitsaccess to entitlements without having to reentitlements at a later date.

[0045] The Revoke Administrator actor initiates the process by accessingthe Revoke User screen of the preferred embodiment DECAF system. TheRevoke Administrator selects which application(s) to work with, thenselects the User actor(s) to work with from the presented list. TheRevoke Administrator has four options; revoke the userid, revokespecific entitlements, groups, or data type values for the User actor orgroup, lock the userid, or unlock the userid. When a User actor_sentitlement(s) or group(s) is revoked, locked, or unlocked an eis sentto the user and manager or POC indicating that his status has changed.

[0046] The preferred embodiment DECAF system provides a securitymechanism to insure that inactive User actors are removed from thesystem and that User actor entitlements remain valid. The mechanism isreferred to as re An administrator initiates the Reprocess. Eare sent toCustomer Owners asking them to rethe User actor profiles they areresponsible for. The econtains a URL which points to a page where thereprocess is accessed. Customer owners may log on to the preferredembodiment DECAF system, go to main menu and then select “Approval” menuand reprofiles by clicking on the pending records that appear below the“ReProfile” or “ReUser Entitlements” link. Customer owners may alsoclick on the URL received in the ePreferably, the present invention useswhat is typically known as a standard three tier webarchitecture on aUnix based machines, and more preferably AIX from IBM Corporation.Alternatively, other similar environments such Windows NT from MicrosoftCorporation or Mainframe based systems may be suitable substitutes.Preferably, the architecture is implemented with a web server,application server, and database server. Server clustering is alsorecommended to increase overall system upand response. The databaseshould reside on within a Relational Database and more preferably DB2Universal Database from IBM Corporation. Web pages are served from a webserver, preferably WebSphere from IBM Corporation.

[0047] Functionality for the preferred embodiment DECAF systemincludes: 1) Direct Enablement projects which would allow a user torequest and receive an entitlement without additional human action. 2)Enhanced maintenance for projects by allowing the addition and deletionof entitlements, movement of entitlements between projects, copingprojects into new projects, and addition of entitlements from all usersdefined to the project. 3) The ability to lock and unlock entitlementssimilar to locking and unlocking userids. Request for access could notbe made against locked entitlements.

[0048] There are no known limitations to the preferred embodiment DECAFsystem.

[0049] It is thus believed that the operation and construction of thepresent invention will be apparent from the foregoing description. Thedescription of the embodiments of the present invention is given abovefor the understanding of the present invention. It will be understoodthat the invention is not to the particular embodiments describedherein, but is capable of various modifications, rearrangements andsubstitutions will now become apparent to those skilled in the artwithout departing from the scope of the invention. Therefore it isintended that the following claims cover all such modifications andchanges as fall within the true spirit and scope of the invention.

1. A distributed control access facility which comprises: an applicationinterface connected to an application for which access is controlled, towhich remote networked users can obtain access and from whichauthorization requests for the user can be issued; at least one servercomprising an access control facility connected to the applicationserver the access control facility comprising: a master setup whichprovides information to the control facility relating to the applicationand entitlements; a request for access facility which receives the userrequest through a user interface, compares user information, to theinformation in the master setup; to determine whether the request shouldbe approved; and an access repository which acts on the information fromthe access facility and returns the appropriate authorization to theapplication.
 2. The facility of claim 1 where the application interfaceis connected to a plurality of applications residing on a plurality ofservers.
 3. The facility of claim 1 wherein the master setup alsocomprises an administration interface from which information regardingthe application name, application description, entitlements, applicationlevels may be defined.
 4. The facility of claim 3 wherein the accessrepository also has the ability to issue access to an application basedon the application level a user is entitled.
 5. The facility of claim 1wherein the entitlement comprises: an entitlement name; an entitlementdescription: level of approvers; and active dates.
 6. The facility ofclaim 1 wherein the entitlement comprises: a separation of duties checkand entitlement types.
 7. The facility of claim 1 wherein entitlementsare grouped into projects, and a user can receive approval on a projectbasis.
 8. The facility of claim 1 wherein the master setup alsocomprises a separation of duties matrix which is defined by an actorcomprise a grid of applications and entitlements and flags atintersections.
 9. The facility of claim 1 where the master setupprovides for the definition of approvers by owners of the application.10. The facility of claim 9 wherein the approvers the master setup alsoprovides for the type of users the approvers will approve.
 11. Thefacility of claim 10 wherein the master setup contains entitlements forboth internal and external users.
 12. The facility of claim 1 alsocomprising a user interface that provides for a registration form. 13.The facility of claim 12 wherein the registration form and master setupprovides for a userid.
 14. The master setup of claim 13 wherein themaster setup provides for revoking the userid.
 15. The master setup ofclaim 1 wherein the master setup provides for re-certification ofentitlements.
 16. A distributed control access facility which comprises:a plurality of servers that are networked; at least one of the serverscomprising an application for which access is controlled, to whichremote networked users can obtain access and from which authorizationrequests for the user can be issued; at least one of the serverscomprising an access control facility connected to the applicationserver the access control facility comprising: a master setup whichprovides information to the control facility relating to the applicationand entitlements; a request for access facility which receives the userrequest through a user interface, compares user information, to theinformation in the master setup; to determine whether the request shouldbe approved; and an access repository which acts on the information fromthe access facility and returns the appropriate authorization to theapplication.
 17. A method for controlling access to an application in adistributed computer networked environment, the networked environmentcomprising an application area and a distributed access controlfacility, comprising the steps of: submitting a user request for accessto an application; issuing through the application the request to thedistributed access control facility along with pertinent userinformation; performing a separation of duties check based on theapplication and the user information; determining the type of user;seeking separation of duties approval based on type of user; andproviding for an override if the user failed the override.
 18. Themethod of claim 17 wherein the types of users comprise external andinternal users.
 19. The method of claim 18 also comprising the step ofrouting the external user request to a point of contact.
 20. The methodof claim 19 also comprising the step of routing the internal userthrough an approval process in the internal user failed the separationof duties check.
 21. A method for controlling access to an applicationin a distributed computer networked environment, the networkedenvironment comprising an application area and a distributed accesscontrol facility, comprising the steps of: attempting through a user toaccess an application in the application area; requesting through theapplication area information regarding the user; sending through theapplication area an authorization request; comparing the informationreceived from the application area and the application to informationcreated in the distributed access control facility in an accessrepository; sending the results of such comparison to the application,and having the application grant access to the application based on theresults of such comparison.
 22. The method of claim 21 wherein the stepof sending the results of such comparison also comprises providing thelevel of access the user has to such application.
 23. The method ofclaim 21 wherein the information created in the distributed accesscontrol facility comprises a user entitlement for the application andthe step of comparing determines the user entitlement for theapplication.
 24. The method of claim 23 wherein the information createdin the distributed access control facility comprises a separation ofduties matrix formed using a plurality of user entitlements andapplications.
 25. The method of claim 24 also comprising the step ofperforming a separation of duties check.
 26. A program storage devicereadable by machine, tangibly embodying a program of instructionsexecutable by the machine to perform method steps for controlling accessto an application in a distributed computer networked environment, thenetworked environment comprising an application area and a distributedaccess control facility, the method comprising the steps of: attemptingthrough a user to access an application in the application area;requesting through the application area information regarding the user;sending through the application area an authorization request; comparingthe information received from the application area and the applicationto information created in the distributed access control facility in anaccess repository; sending the results of such comparison to theapplication, and having the application grant access to the applicationbased on the results of such comparison.
 27. The method of claim 26wherein the step of sending the results of such comparison alsocomprises providing the level of access the user has to suchapplication.
 28. The method of claim 26 wherein the information createdin the distributed access control facility comprises a user entitlementfor the application and the step of comparing determines the userentitlement for the application.
 29. The method of claim 28 wherein theinformation created in the distributed access control facility comprisesa separation of duties matrix formed using a plurality of userentitlements and applications.
 30. The method of claim 29 alsocomprising the step of performing a separation of duties check.